AWS Transit Gateway をVPCにアタッチメントしたTransit Gateway専用サブネットのルートテーブルのルート設定について

AWS Transit Gatewayに入門し、公式ドキュメント、技術ブログを参考に学習していました。何点か疑問がでてきたので手を動かして確認した記録です。

疑問

1. Transit GatewayをVPCにアタッチメントしたTransit Gateway専用サブネットのルートテーブルの設定内容
2. クロスアカウントで共有先のサブネットにTransit GatewayのENIが作成されるタイミング
3. クロスアカウントのVPC間通信を実現する検証環境構築までの所要時間

1番はTransit Gatewayを介してVPC間通信したいEC2などが起動しているサブネットのルートテーブルにTransit Gateway行きのルートがあればよいはずです。単純なVPC間の接続用途でTransit Gateway専用サブネットのルートテーブルには何を設定しておけばよいのか。

2番はクロスアカウントの場合はどのタイミングでENIが作成されるのか気になった。

3番は急ぎ検証したいとなったときに環境構築するまでの工数を把握したかった。

という理由でTransit Gatewayを介したVPC間通信する環境を構築しながら疑問を解消します。

結論

1. 本環境においてはTransit Gateway専用サブネットのルートテーブルに特別なルートは必要ない
2. Transit Gateway共有元のアカウントで共有先アカウントからのアタッチメントの承諾要求に承諾したタイミング
3. 本環境を再構築するのには50分みておけば十分

検証環境の概要

Transit GatewayをVPCにアタッチするときは専用のサブネットにとベストプラクティスで触れられています。

• Transit gateway design best practices - Amazon Virtual Private Cloud

以下の構成でVPC間通信できるか確認します。

以下のリンクと構成、実施内容ともにほぼ同じです。UIが変更されていたため現時点のUIのキャプチャを取得したことと、個人的な疑問にスポットをあてて進めます。

• Transit Gatewayでアカウント跨ぎのVPC間通信をやってみた | DevelopersIO

Transit Gatewayで登場する用語、必要要素は以下のリンクで非常にわかりやすくまとまっております。細かい説明は省き環境構築した手順を紹介しますので、必要に応じて「絵でみて（完全に）理解」してください。

• クロスアカウントな AWS Transit Gateway を、絵で見て（完全に）理解する。 | DevelopersIO

Transit Gatewayの作成と共有

前提として、Transit Gatewayの共有元（アカウントA）と、共有先（アカウントB）にVPCが構築した状態からはじめます。共有元のVPCは既存の検証環境のVPCを流用し、共有先のVPCは新たに作成しました。

共有元と、共有先アカウントと個別に必要な作業を順を追って確認します。

共有元（アカウントA）

Transit Gatewayを作成します。共有アタッチメントを自動承諾せず確認してから手動で承諾したいためチェックは外したままです。

3分ほどでステータスがAvailableになりました。

作成したTrangit Gatewayを他アカウントから利用できるようにResource Access Manager（RAM）から共有します。

共有先のアカウントIDを入力して追加します。

追加すると「選択されたプリンシパル」から追加したアカウントIDを確認できます。

内容確認後、「リソース共有を作成」をすれば作業完了です。

自分が共有のリソースの共有から、共有しているリソースにTransig Gatewayが表示されます。

Transit Gateway作成から共有までの所要時間は約10分でした。

共有先(アカウントB)

共有先のアカウントに切り替えました。RAMを開き、リソースの共有にある1件の招待を確認します。

承認します。共有先側は共有元のTransit Gatewayを受け入れるという承認が必要なんですね。

ステータスがActiveになりました。

Transit Gatewayのアタッチメントを行います。Transit Gateway IDで共有元Transit Gatewayを選択できるようになっています。Transit GatewayのENIを作成するサブネットを指定します。

ステータスがPending Acceptanceでリソースが作成されました。共有先でのアタッチ作業完了です。

Transit Gatewayの共有受け入れ承認をして、アタッチ指定までの所要時間は約5分でした。

現時点ではTransit GatwayのENIは指定したサブネットに作成されていません。

共有元（アカウントA）

共有元のアカウントに戻しました。Transit Gatewayのアタッチメントを確認するとPending Acceptanceのリソースが追加されています。共有先からのアタッチ要求です。

承諾します。自動承諾設定ではないので確認してから手動でポチります。

ステータスがPendingになりました。この間に共有先アカウントの指定したサブネット内にTransit GatewayのENIが作成されました。ENIの作成タイミングは共有元で承諾したときでした。

アタッチメントのステータスは双方のアカウントでAvailableとなりました。

共有元も共有したいVPCのサブネットにTransit Gatewayのアタッチメントを作成します。

ステータスがPendingになりました。Transigt Gatewayを所有しているアカウントなので承諾はなく進みます。

約2分でAvailableになりアタッチメントが完成しました。

共有先のアタッチメント承諾から共有元のアカウントでアタッチメント作成までの所要時間は約10分でした。

サブネットのルートテーブル設定

Transit Gateway ルートテーブルというサブネットに紐付けるいつものルートテーブルとは異なる種類のルートテーブルが存在します。

Transit Gateway作成時にデフォルトルートテーブルの関連付けと、デフォルトルートテーブル伝搬を有効化していたので共有元と共有先のVPC CIDRが登録されています。

サブネットのルートテーブルにルート追加

クロスアカウントで対向のVPCへルーティングしたいリソース（EC2インスタンスなど）が起動しているサブネットのルートテーブルにルートを追加します。対向のサブネットのCIDR宛にターゲットはTransit GatewayのIDを指定します。ターゲットで指定するのはTransit GatewayのENIではなくTransit Gateway自体でした。

共有先も同様です。共有先も共有先のアカウント内にあるTrangit GatewayのENIではなく、共有元からRAMで共有されたTransit GatewayのIDを指定します。

Transit Gateway ENIの専用サブネットのルートテーブルは？

共有元、共有先共通事項です。Transit Gateway専用サブネットに作成したTransit GatewayのENIがあります。専用サブネットのルートテーブルに特別な設定が必要なのか？リソース（EC2インスタンスなど）が通信するサブネットは別にあるため、専用サブネットのルートテーブルにTransit Gateway宛のルートは必要ありませんでした。デフォルトのローカルのみのルーティングだけ設定しています。

セキュリティグループ設定

共有元、共有先共通事項です。今回はTransit Gatewayを介したVPC間通信にEC2からEC2へPingで疎通確認を行います。双方のEC2のセキュリティグループにICMPを許可するルールを追加します。というのがベストですが、いろいろ試したいことがあるのですべてトラフィックを許可します。

• さまざまなユースケースのセキュリティグループのルール - Amazon Elastic Compute Cloud

ソースには対向サブネットのCIDRを指定しました。さすがに対向のEC2のセキュリティグループ指定はできませんでした。

Transit Gateway経由したVPC間の疎通確認

共有元、共有先のVPC内のサブネットで起動しているEC2からプライベートIPアドレス宛にPingで疎通確認します。

成功しました。Transit Gatewayアタッチ後にサブネットのルートテーブルと、セキュリティグループの設定追加でVPC間の疎通確認まで取れることがわかりました。

まとめ

Transit Gateway ルートテーブルと、お馴染みのサブネットのルートテーブル2種類が登場します。混同しないように注意が必要。

あとはEC2などのリソースは必要に応じてセキュリティグループの許可を追加。

再掲になりますが大事なことや、Transit Gatewayで登場する用語は以下のリンクで大変わかかりやすく説明されています。

おわりに

試せてはいないですけどTransit Gateway専用サブネットのルートテーブルに変更するときは以下のケースではないかと。

• 20191113 AWS Black Belt Online Seminar AWS Transit Gateway

Q. VPC をアタッチするときに指定するサブネットをアタッチ専用のサブネットとする必要性について、もう少し具体例を挙げて説明していただきたいです。そのサブネットの内部のEC2 インスタンスのルーティングに影響あるとのことでしたが、どのような影響があるのか？などを教えていただきたいです。

A. Transit Gateway (TGW) のアタッチメントがついているサブネットと同一のサブネットに EC2 インスタンスが存在する場合に、その EC2 インスタンスはTGWと同じルーティングテーブルを参照します。 例えば　インライン監査用の VPC の TGW の ENI がある Subnet 上に EC2 インスタンスを設置してしまうと、その EC2 インスタンスは必ずインライン監査のミドルボックス ENI に吸い込まれてしまい、EC2 インスタンスの意図するルーティングテーブルを作れなくなってしまいます。こういったことを防ぐために、TGW 専用のサブネットを作ることをお薦めしています。 こちらおよびこちらの資料を併せてご参照ください。

引用元: [AWS Black Belt Online Seminar] AWS Transit Gateway 資料及び QA 公開 | Amazon Web Services ブログ

CloudFormationでテンプレート化するときは以下のリンクが参考になるかと思います。依存関係のハマりどころに触れられていますのでCloudFormationで構築する方はご一読されるとよいでしょう。

Transit GatewayをCloudFormationで構築してみた | DevelopersIO